Some enterprise application servers store not only the application data and application customization data in database tables, but also other data, especially the application software shipped by third parties (e.g., vendors, etc.). This approach has several advantages such as having a consistent backup/recovery mechanism for application software and data and is especially useful for applications generating code. On the other hand, depending on how the application software is stored in the database, inclusion of such data in database tables can also create difficulties during installation and update procedures.
A system, where the software is stored in the database can be delivered as a database (DB) load. In such an arrangement, a “delivery system” is set up at the vendor and all components and content that shall be part of the system are deployed to the delivery system database. A “load delivery package” can now be created, containing a description of all table structures and tables content. Using this load delivery package, a customer can setup a system by installing a database, creating the required tables and loading the database content. This approach results in a very fast setup time as there is low processing overhead and the duration is mainly dependent on the DB IO performance.
To ship a system with optional components (a component, where the customer can decide at setup time if it shall be installed or not) the approach described above cannot be used. Only a subset of mandatory components can be deployed at the vendor to the delivery system and exported from the DB and thus be part of the load delivery package.
The optional components a customer wants to deploy on top of the system are treated with the standard deployment mechanism of the system (e.g. with transports for SAP ABAP and deployment for Java). Depending on how the software is stored in the database and which artifacts are shipped, these deployment mechanisms (e.g. transport) are slower compared to the DB load. This is due in part because the DB content of a component is spread over a large set of DB tables and out of these tables, single keys need to be deployed. The effect is, that the DB import is performed row based which is a lot slower than DB load. However, this is still faster compared to required computations upon import.
During deployment (transport) not only do table rows need to be imported, but in addition, programs are executed to compute the DB table entries out of “transport artifacts”. As an example for SAP ABAP, a data dictionary definition is imported (e.g. for a table), the structure of the table is computed within the system (depending on the structure of used data elements, domains, structures, etc.) In current SAP delivery this step can take several hours for larger packages. For a logical transport object the “after-import-method” is called. In current SAP delivery this step can also take several hours. That being said, a deployment or transport mechanism can have advantages compared to a DB load such as the ability to ship smaller entities (e.g. deltas, etc.) and the shipment of an application is less dependent on the version of the application server.)
The setup time of a system in which the platform (with the mandatory components) is loaded and the optional components are deployed is therefore longer as compared to a setup of a system where the platform and the other components are part of the load. For example, for an SAP ERP system with Enhancement packages this can be more than 10 hours longer). An additional factor is the error-proneness of deployment, because a large set of tasks need to be performed, compared to the DB load, where only one generic import tool is used.